On Tue, May 26, 2015 at 10:40 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

[Attachment(s) from Tom Kerekes included below]

Hi SJH,

I did some research and was able to capture some data and also I think feel the "knocking" you describe with your GCode when using abnormally high resolution.

I think you are correct and the issue is caused by a small error in specified radius and/or begin/end points in the GCode due to the number of digits specified.  The errors are ~1um which result in a discontinuity of that amount which results in a burst of a few step pulses to "jump" that small distance to begin the next arc.  It isn't clear to me why there is a loss of position for you.  Have you determined if you end up off by a motor pole (1/50th of a rev), or are the step pulses too fast to be received by the drive?   Another thing to check is if it might be something else like the direction setup time.  This is a common problem where the drive interprets the step in the wrong direction on a reversal.

I think we are just losing some steps; the servos are 3-phase and emulate step/direction.  There would probably be a bigger 'clunk' if it was losing a whole phase, and we'd see the Output var shoot up by more than a few counts.  Our servo motors are configurable, so we can reduce the required step frequency by 5.12 so we don't need that excessive output gain (my colleague is trying that now).  We might also give the inverted step pulse a try.  We are using Clearpath servo motors, but I couldn't find anything in their manual about required setup time.

 

I found that specifying the arc using the R (radius) Gcode Mode seems to eliminate the problem.  This naturally computes an arc center to perfectly go through the specified beginning and end points.  I also modified mad a test Version of the GCode Interpreter that basically converts IJ mode to R mode automatically.  This essentially adjusts the arc center such that the arc will then go exactly through the start and end points.  It seems to work in all the cases I tested but I worry that certain cases may have numerical problems.  Specifically trying to specify a semi-circle with two points and a radius might result in significant errors in determining the arc center.  I'll attach the source file based on V4.33l if you want to try it.  

We can certainly use R format arcs, but the trouble is we will have no control over what post processor options our customers use.

 

I'm assuming you do not have the Trajectory Planner option set for  "Arcs to segments".  This also seems to solve the problem and has other advantages.  Firstly, point to point line segments are inherently continuous.  Secondly the Trajectory planner is able to apply "Corner Rounding" to smooth transitions between arcs that would otherwise not be smoothed.  I've noticed ~4 degree sudden angle changes between arcs in the GCode fragment you sent.  Thirdly the TP will fully optimize motion throughout the arcs rather than once for each arc which will improve performance if you are acceleration or velocity limited in any way.

Let me know what you think.

Regards

TK

I tried using arcs to segments, but that just made it worse - got following errors in just a few seconds.  So I tried some other things: we have some velocity feed-forward, so I zerod that out, and it fixed it!  OK, so it seems that having any feedforward is going to send a big bunch of step pulses when direction changes.  We would like to have the feed forward, since it compensates some response lags in our system,  Is there any way to have that and yet limit the rate that step pulses are sent out?

Regards,

SJH

 

Group: DynoMotion	Message: 11582	From: Tom Kerekes	Date: 5/26/2015
Subject: Re: Strange behavior with connected g2 arcs

Hi SJH, The Arcs as Segments should work well.  Possibly you had large TP Tolerance Settings?  Those control how smoothly the segments follow the Arc.  In your case they should be around 1um (0.00004 inches). But regarding Feed Forwards:  Any position discontinuity would cause a large spike in velocity which would cause a spike in the commanded output position.  If you look at this diagram: You can see that the FF signals are passed through the 3rd IIR filter.  If you set this to something like a 2nd order low pass filter 300Hz Q=1.4 it should reduce the amplitude of any spike. But it seems like it would be better to address the root cause. Regards TK Group: DynoMotion Message: 11583 From: Hardy Family Date: 5/26/2015 Subject: Re: Strange behavior with connected g2 arcs On Tue, May 26, 2015 at 5:01 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:   Hi SJH, The Arcs as Segments should work well.  Possibly you had large TP Tolerance Settings?  Those control how smoothly the segments follow the Arc.  In your case they should be around 1um (0.00004 inches). Not sure what you mean by "TP tolerance" (although, having teenage girls, it sounds like I need some of that.)  I had the corner rounding set to 2.5um which should be OK for this job. But yes, setting the third IIR filter smoothed things out to the point where I can even have a bit of accel FF, which helps anticipate flex in the machine.  I do need to set the bandwidth to 50Hz for that.  Things will probably be even better when we don't need the high output gain. Regards, SJH   Group: DynoMotion Message: 11584 From: Tom Kerekes Date: 5/27/2015 Subject: Re: Strange behavior with connected g2 arcs Hi SJH, TP=Trajectory Planner. The Collinear Tolerance would be what determines the smoothness of the arcs.  If you get a chance please try Arc to Segments with a small Collinear Tolerance (ie 1um = 0.00004). Regards TK Group: DynoMotion Message: 11588 From: Hardy Family Date: 5/27/2015 Subject: Re: Strange behavior with connected g2 arcs Hi Tom, Setting the tolerances to 1um works fine, although my colleague encountered a related problem when doing this.  We have some code which contains very small helical motion, using G2 arcs.  If we use "arc to segment", with a high enough feed rate, and a small enough facet angle, then we get "unexpected buffer underrun" errors.  I suspect that the USB is the bottleneck, since it would be sending a large quantity of very small moves. We can work around this by unchecking "arcs to segments" and/or reducing feedrate and/or increasing the facet angle. Is there anything else we could do to prevent the buffer problem?  I think we fixed the arc discontinuity satisfactorily by adding the third IIR as a low pass, so it would be preferable not to break up arcs into segments (certainly it seems smoother on the machine with real arcs).  Hopefully our customers won't be doing too much crazy stuff like our testing, but it would be nice to get it as robust as possible. Regards, SJH On Wed, May 27, 2015 at 8:25 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:   Hi SJH, TP=Trajectory Planner. The Collinear Tolerance would be what determines the smoothness of the arcs.  If you get a chance please try Arc to Segments with a small Collinear Tolerance (ie 1um = 0.00004). Regards TK Group: DynoMotion Message: 11589 From: Tom Kerekes Date: 5/27/2015 Subject: Re: Strange behavior with connected g2 arcs Hi SJH, What size facet angle were you specifying?  Could you post a GCode Fragment and all your settings?  KFLOP should be able to handle ~2000 segments/sec which normally far higher than the rate most systems can changed direction. The later test versions (ie V4.33l) may be better optimized and will slow down the feedrate rather than underrun the buffer. Regards TK Group: DynoMotion Message: 11590 From: Hardy Family Date: 5/27/2015 Subject: Re: Strange behavior with connected g2 arcs Attachments : GCodeConfigCNC-11590(1).txt bore fail-11590.NC Hi Tom, I was using 1 degree.  Changing it to 5 degree made it work.  The attached init file has the original 1 deg setting. Regards, SJH On Wed, May 27, 2015 at 6:11 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:   Hi SJH, What size facet angle were you specifying?  Could you post a GCode Fragment and all your settings?  KFLOP should be able to handle ~2000 segments/sec which normally far higher than the rate most systems can changed direction. The later test versions (ie V4.33l) may be better optimized and will slow down the feedrate rather than underrun the buffer. Regards TK Group: DynoMotion Message: 11597 From: Tom Kerekes Date: 5/28/2015 Subject: Re: Strange behavior with connected g2 arcs [2 Attachments] Hi SJH, Thanks.  That file is indeed demanding.  < 0.1mm helex at 300mm/sec. I do see a buffer under run on V4.32 but V4.33l works fine with Arcs-to-segments set and runs without any feed rate reduction due to buffering. I would expect Arc-to-segments to be just as smooth and have other advantages like removing "kinks" between arcs. Regards TK